\section{Applications}\label{sec:apps}

We used \sys to build several full embedded system applications.  To illustrate
the benefits of \sys, we built applications that have several properties.
First, the application explicitly uses non-volatile data.  Second, the
application has consistency requirements on its non-volatile data.  Third, the
application requires application-specific recovery actions.  Fourth, the
application is a realistic example of something others may build to run off of
harvested energy.  We used these applications in our evaluation
(Section~\ref{sec:eval}).


\subsection{Activity Recognition}
We implemented a general Activity Recognition (AR) platform.  Our hardware
setup tracks acceleration using an Analog Devices ADXL326z low-power
accelerometer. The accelerometer is connected to an MSP430FR5969
microcontroller to communicate via 4-wire SPI.  We provide rudimentary I/O
through a manual push-button reset and a series of LEDs that, when configured,
report the classification.

Our software AR framework implements a general binned naive bayes classifier.
The classifier's model is provided at build time ({\em i.e.}, offline
training).  The software collects accelerometer readings and stores them in a
heap-allocated time series.  The time series is processed by activity-specific
featurization code and the result is stored in a heap-allocated feature vector.
Each feature vector is classified and its result accumulated in a set of
statistics that track the total number of samples and the total number of
samples per class.

Building on our framework, we built a demo AR application that tracks time
spent walking, simliar to FitBit~\xxx{CITE FITBIT}.  The model has two classes:
walking and stationary.  We maintain a three entry time series of three
dimensional accelerometer readings.  The featurization code tranforms time
series to two-feature vectors that contain the magnitude of the mean vector and
the magnitude of the standard deviation vector, similar to prior work~\xxx{cite MSR
OOPSLA LAB paper}.

Our AR benchmark has our four benchmark characteristics.  It is a timely and
realistic application currently that runs on a battery today. AR requires
explicit non-volatile memory manipulation because per-class statistics must be
persistent to be useful.  AR must ensure that per-class classification counts
are updated atomically with the total classification count and that all counts
are not updated multiple times for a single sample.  AR requires
application-specific recovery for several reasons.  In systems with a volatile
heap, like our test platform, recovery recreates the time series and feature
vector objects.  In systems with a non-volatile heap, recovery checks the
validity of the time series data by comparing with an accelerometer reading. If
the readings differ considerably, the device's environment must have changed,
the readings in the time series are outdated, recovery reinitializes the time
series. 





Using our platform, we

Activity recognition.  Persistent sample set, featurization, classification,
state machine for overall process.

Simon game: pattern of LEDs.  Persistent game state: score, state machine (phase
of the game).

Noise meter: persistent sample buffer, ground truth is a SPL meter from Radio
Shack.  We used an Analog Devices ADMP801Z-FLEX MEMS microphone with a built-in
power amplifier that requires $x\,\text{mA}$ to operate.  We gated the
microphone with a GPIO pin so that it was on only when we were sampling sound.
We sampled the microphone with the onboard ADC at $y\,\text{Hz}$ and used the
total voltage to measure sound amplitude.  We calibrated against a Radio Shack
$XXX$ sound pressure level (SPL) meter.

Peppermill board~\cite{peppermill}.  We reproduced the Peppermill experiment,
which did $X$.

Communication protocol based on radio.  We used a TI CC2500 radio attached to
the SPI bus of our Wolverine evaulation board.
